The present invention relates to a method for processing affinity sets of related messages in a messaging and queuing system.
In recent years, the ability of application programs to communicate with each other or with system provided services in a computer system or network without having to become involved in the complexities of particular operating systems or communication protocols has been much enhanced by the development of Message Oriented Middleware (MOM). This is software running on top of a computer operating system which provides a common programming interface by means of which applications can communicate with other applications without specific knowledge of the different operating systems and/or protocols which may be used by those applications.
One example of Message Oriented Middleware (MOM) is the IBM WebSphere MQ product family. The most recent version, WebSphere MQ for z/OS Version 7.0 (“IBM”, “WebSphere” and “z/OS” are trademarks of International Business Machines Corporation), is described in an Information Center on the IBM Corporation website.
WebSphere MQ and other MOM products employ message queuing which allows programs to send and receive application specific data to each other without having a private, dedicated logical connection established between them. Instead, the applications communicate using messages containing a message descriptor and the application specific data. The messages are held on queues by a queue manager. The queue manager is effectively the runtime component of the MOM product and may also be referred to as a messaging server.
These queues may be accessed directly by applications on the same system using the same queue manager or their contents may be transmitted over a network or multi node system and placed on respective associated queues accessible to a receiving application via its respective local queue manager. In order to transmit messages to remote applications, the originating queue manager must first establish a communication channel to the remote queue manager. Both transmission and accessing of queued messages take place asynchronously.
Applications communicate with their associated queue managers via a standard application programming interface (API), known as the Message Queuing Interface (MQI) in the case of WebSphere MQ. Specific MQI commands cause the queue manager to store (MQPUT) messages on named destination queues, either directly, if local, or by transmitting them to the appropriate queue manager at a node elsewhere in the system and also to retrieve (MQGET) stored messages from such queues. A queue can be both a source of messages and a destination for messages.
Before an application program can put or get messages from a queue, it must first connect to the queue manager hosting the queue by means of an MQCONN call. The queue manager responds by returning a connection handle, sometimes referred to as Hconn, which is a unique identifier by which the program knows the queue manager. The program can then open the queue by supplying the connection handle as a parameter of an MQOPEN call, which establishes access to an object such as a queue. The output from the MQOPEN call includes an object handle, Hobj, which is an identifier by which the program knows the queue (or any other object) and is used as an input parameter for any subsequent MQI calls to the same queue. When an application has finished putting or getting messages from a queue, it normally closes the queue by means of an MQCLOSE call, specifying the appropriate object handle.
All MQI calls also require the selection of a number of other options or parameters, depending on the precise purpose and context of the operation to be carried out.
In large or heavily used messaging and queuing systems, problems of system administration, availability and workload balancing have been tackled by the use of clusters. Clusters are networks of queue managers that are logically associated. Communication between queue managers in a cluster is much simpler than between unrelated queue managers. Repository queue managers, to which all queue managers have access, have full knowledge of all queue managers in the cluster. Cluster queues are just queues hosted by a cluster queue manager and may be advertised to other queue managers within the cluster to simplify communication.
One aspect of clusters which is important in terms of workload balancing and availability is that more than one queue manager in the cluster can host an instance of the same queue. Because of this, the workload can be distributed between these queue managers, thereby increasing availability. Any one of the queue managers that hosts an instance of a particular queue can handle messages destined for that queue. This means that applications need not explicitly name the queue manager when sending messages. A workload management algorithm determines which queue manager should handle the message.
However, if, in order to benefit from workload management, a messaging and queuing network is set up to have multiple definitions (instances) of the same queue, it is always necessary to consider whether the applications using the system may have message affinities, that is, they exchange related messages which need to be processed on the same instance of a queue.
Because, with this type of cluster, a message can be routed to any queue manager that hosts a copy of the correct queue, the logic of applications with message affinities can be affected. Suppose for example, two applications rely on a series of messages flowing between them in the form of questions and answers. It might be important that all the questions are sent to the same queue manager and that all the answers are sent back to the other queue manager. In this situation, it is important that the workload management routine does not send the messages to any queue manager that just happens to host a copy of the correct queue. Similarly, some applications might require messages to be processed in sequence, for example a file transfer application or database replication application that sends batches of messages that must be retrieved in sequence.
In general, therefore, it is desirable to remove message affinities from applications as far as possible before starting to use clusters. Removing message affinities improves the performance of applications. For example, if an application that has message affinities sends a batch of messages to a queue manager and the queue manager fails after receiving only part of the batch, the sending queue manager must wait for it to recover before it can send any more messages, thereby degrading performance.
Removing messages affinities also improves the scalability of applications. A batch of messages with affinities can lock resources at the destination queue manager while waiting for subsequent messages. These resources may remain locked for long periods of time, preventing other applications from doing their work.
If message affinities can be removed so that it is not necessary to force all messages to be written to the same destination, an option MQOO_BIND_NOT_FIXED is specified on the MQOPEN call. This defers selection of a destination until MQPUT time, that is, on a message-by-message basis. Selection may then be made as determined by the cluster workload management algorithm.
However, removing message affinities in a clustered system is not always possible. The main problem to which the current invention relates is the limitation that message affinities prevent the cluster workload management routines from making the best choice of queue manager.
In such cases, where it is not appropriate to modify applications to remove message affinities, a number of partial solutions to the problem have been proposed. One solution is to specify the remote-queue name and the queue manager name on each MQOPEN call. In this case, all messages put to the queue using that object handle go to the same queue manager, which might be the local queue manager. This makes the application responsible for choosing queue managers in the cluster, something that the cluster software itself should be managing.
A variation on this solution is to allow the queue manager that receives the first message in a batch to return its name in response. The queue manager at the sending end can then extract this queue manager name and specify it on all subsequent messages. The advantage of this method over the previous one is that some workload balancing is carried out to deliver the first message.
The disadvantage of this method is that the first queue manager must wait for a response to its first message before sending subsequent messages. As with the previous method, if there is more than one route to the queue manager, the sequence of the messages might not be preserved.
The currently preferred solution is to force all messages to be put to the same destination within the cluster, by specifying an option MQOO_BIND_ON_OPEN on the MQOPEN call. By specifying MQOO_BIND_ON_OPEN, all messages that are sent to this queue are forced to be sent to the same queue manager and thus to the same instance of the queue. MQOO_BIND_ON_OPEN binds all messages to the same queue manager and also to the same route. For example, if there is an IP route and a NetBIOS route to the same destination, one of these will be selected when the queue is opened and this selection will be honored for all messages put to the same queue using the object handle obtained.
By specifying MQOO_BIND_ON_OPEN all messages are forced to be routed to the same destination. Therefore applications with message affinities are not disrupted. If the destination is not available, the messages remain on the transmission queue until it becomes available again.
All of the above known solutions have the limitation, however, that each queue hosting a set of affinity messages must be separately opened with MQOPEN, restricted according to the above suggested solutions and then closed with an MQCLOSE call before workload management can be resumed for other message processing tasks of the application which do not have affinities or before different affinity sets can be processed. Opening and closing queues in this way consumes both time and resources.